Computerized systems provide many advantages towards peoples' ability to perform tasks. Indeed, the computer systems ability to process information has transformed the way we live and work. Computing systems now take a wide verity of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistances (PDAs), and the like. Even household devices (such as refrigerators, ovens, sewing machines, security systems, and the like) have varying levels of processing capability, and thus may be computing systems. Processing capabilities continue to be incorporated into devices that traditionally did not have such processing power. Accordingly, the adversity trend of computing systems will likely increase.
Along with computing systems, the Internet has revolutionized the way people communicate and has ushered in a new era in human history often termed the “information age.” In essence, the Internet includes a large constellation of networked computers that are spread out over much of the world. Sophisticated computers, software, and networking technology have made communication over the Internet fairly straight forward from the view point of the end user. In order to communicate over a network, typically one computing system constructs or otherwise accesses an electronic message and transmits the electronic message over a network to another computing system. Portions of the electronic message may be read by human users as when the electronic message is an email, instant message, an appointment, or the like. Alternatively, or in conjunction, the electronic message may be read by an application running on the receiving computing system. The electronic message may further be constructed by an application running on the sending computing system with the possible assistance of a human user.
When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., parsing, routing, flow control, etc.). The Open System Interconnect (OSI) model is an example of a network framework for implementing a protocol stack. The OSI model breaks down the operations for transferring an electronic message into seven distinct layers, each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network.
When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to the higher intermediate layers and then is eventually received at that application layer. The application layer—the upper most layer—is responsible for supporting application and end-user processing. Further, within the application layer there may reside several other layers (e.g., the Simple Open Access Protocol (SOAP) layer). Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer is the Transmission Control Protocol (TCP).
In some environments, applications communicate with one another using the above OSI model and queued message communication. Queued communication includes mechanisms for a sending application to write a message into a sending queue, the sending queue to transfer the message to a receiving queue, and for a receiving application to read the message from the receiving queue. The queues maintain communication state outside of the communicating parties, and provide a level of abstraction between them. Accordingly, queued messaging provides reliable communication between loosely coupled applications. Senders and receivers of messages use intermediary queue managers to communicate, and may independently shut down and restart and may even have non-overlapping lifetimes. Queuing also allows clients and servers to send and receive messages “at their own pace” with the queue taking up the slack at either end.
One model of a queued messaging system is a published/subscribed (often termed pub-sub), which is an event driven architecture with the notions of subscriptions, events, and notifications. A subscription is a request made by a consumer or registrar (herein referred to as a “subscriber”) to a data store or service (herein referred to as a “publishing service”), expressing interest in some change thereto (typically by specifying a scope and a criterion). Events, on the other hand, are actual changes that happen in the data server or service. When an event happens in a publishing service for which interest was expressed by a subscription, a notification is published and subsequently sent to a registrar or subscriber of that subscription notifying them of the event.
There are many examples of such pub-sub or other notification uses. For example, a user with online access that has previous booked or otherwise scheduled travel arrangements such as flight plans, hotel accommodations, car rentals, and meeting schedules may wish to be notified of any changes in his travel plans. Accordingly, a subscription can be developed that periodically polls one or more servers or services with knowledge of the user's travel plan events. Any changes identified may be reported to the registrar, which may then inform the user thereof.
Another example of where subscriptions are useful is in an email type environment where a user wishes to be notified of certain events and/or assigns an assistant to act on behalf of such events. For example, the user or an assistant may wish to know of events such as: when appointments have been scheduled and/or changed; the arrival of urgent email messages; when messages or folders have been created, deleted, updated, etc.; activities that happen on specific mailboxes; and other various events. Upon notification, the user or assistant may take action as appropriate.
Although pub-sub systems provide a convenient way of notifying users and/or assistants of events, existing implementations have no mechanism for determining if the subscription is active and/or if connectivity exists between the subscriber/registrar and the publishing service applications. As such, in the absence of received notifications, the subscriber or user will not know if there are no notifications to be received or if the system is otherwise inoperable. Although one solution may be to utilize the reliability mechanisms currently built into some of the underlying transport protocols (e.g., HTTPR (Reliable Hyper Text Transport Protocol), TCP/IP (Transmission Control Protocol/Internet Protocol), etc.), such implementation would still have several short comings.
For example, the subscriber (and possibly even the publishing service) would need dedicated code independent of the publishing service for communicating and ascertaining state from the lower communication layers. Accordingly, the needed code may not be within the skill set of a typical pub-sub developer and is also prone to human error. In addition, even if the subscriber (or even publishing service, as the case may be) is able to communicate with the lower layers of the transport, because these lower layers have no direct communication with the application layer, only connectivity across the various transport layers can be determined. Accordingly, the subscriber (and/or publishing service) would only know that the connection between the communication layers is active. The subscriber, however, would not know if the connection between the applications is alive and/or if the publishing service and/or subscription are active. As such, the problem remains that in the absence of notifications, the subscriber would not know if no notifications are available and/or if the publishing service is otherwise inoperable—due to such things as expiration of the subscription and/or fault from the publishing service.